Managed Microsoft ADと信頼関係にあるセルフマネージドADのユーザーを使ってAmazon WorkSpacesを作成してみた
信頼関係が片方向で良いのか分からない
こんにちは、のんピ(@non____97)です。
皆さんはAmazon WorkSpaces(以降WorkSpaces)を使うとき、参照しているManaged Microsoft ADと信頼関係を組んでいるADの信頼関係の方向が気になったことはありますか? 私はあります。
AWSの公式ドキュメントを確認すると、双方向でも片方向でもどちらでも良いと記載しているものもあれば、双方向でなければならないと記載しているものがあります。
- 双方向でも片方向でもどちらでも良いと記載しているドキュメント
オンプレミスの認証情報を使用して WorkSpaces の管理と Workspaces による認証を行い、WorkSpaces をオンプレミスのユーザーとグループに対してプロビジョニングするために一方向または双方向の信頼を使用できます。詳細については、「Set up a one-way trust for Amazon WorkSpaces with AWS Directory Service」を参照してください。
- 双方向でなければならないと記載しているドキュメント
Amazon Chime、Amazon Connect、Amazon QuickSight、AWS IAM Identity Center (successor to AWS Single Sign-On)、Amazon WorkDocs、Amazon WorkMail、Amazon WorkSpaces、AWS Management Console などの AWS エンタープライズアプリケーションでは、双方向の信頼が必要になります。
インターネット上で確認できる例では双方向で信頼関係を作成して、信頼しているドメインのユーザーを使ってWorkSpacesを作成しているものばかりでした。
ということで、片方向で信頼関係を作成して、信頼しているドメインのユーザーを使ってWorkSpacesを作成できるか確認してみます。
いきなりまとめ
- Managed Microsoft ADが信頼しているドメインのユーザーのAmazon WorkSpacesを作成する場合は、双方向の信頼関係である必要がある
- Managed Microsoft ADからセルフマネージドADに対して片方向の信頼関係を作成している場合、セルフマネージドADのユーザーを参照しようとするとエラーになる
- 信頼しているドメインのユーザーでWorkSpacesを作成する場合、WindowsのバンドルでWorkSpacesを作成する必要がある
- Linuxのバンドルだと、WorkSpaces接続時に証明書のエラーが出力されて接続できない
- Managed Microsoft ADが信頼しているドメインのユーザーでWorkSpacesを作成すると、Managed Microsoft ADのUser OU配下にそのユーザー名と同じユーザーが作成される
検証環境
検証の環境は以下の通りです。
Managed Microsoft AD(managed-msad.non-97.net)からセルフマネージドAD(corp.non-97.net)に対して片方向の信頼関係を作成しています。
この状態で、以下AWS公式ドキュメントをベースに信頼しているドメインのユーザーでWorkSpacesを作成します。
Managed Microsoft ADや各EC2インスタンス、Route 53 Resolver Outbound EndpointなどほとんどのリソースはAWS CDKでデプロイします。使用したコードのリポジトリは以下です。
セルフマネージドADの構築
セルフマネージドADを構築します。
まず、下準備です。
AWS CDKでデプロイしたEC2インスタンスにキーペアの設定をしていなかったのでローカルのAdministrorのパスワードが分かりませんでした。そのため、SSMセッションマネージャーでEC2インスタンスに接続し、net userでローカルのAdministratorのパスワードを設定します。
> net user administrator <ローカルのAdministratorのパスワード> The command completed successfully.
パスワード設定後、SSMセッションマネージャーでポートフォワーディングをしてRDP接続します。
# SSMセッションマネージャーで、セルフマネージドADのEC2インスタンスに対してRDPのポート3389をローカルマシンの13389にポートフォワーディング
aws ssm start-session \
--target <セルフマネージドADのEC2インスタンスのID> \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3389"],"localPortNumber":["13389"]}'
接続後、ローカルのAdministratorでログインしていることを確認します。
> whoami ec2amaz-qmr4i25\administrator
下準備ができたので、以下記事を参考にセルフマネージドADを構築します。
新しいフォレストとしてcorp.non-97.netドメインでAD DSを作成します。それ以外は全てデフォルトの設定で作成しました。
AD DSの設定が完了すると、OSの再起動を求められるので再起動を行います。
再起動後corp.non-97.net\AdministratorでRDP接続します。接続後、ドメインのAdministratorでログインしていることを確認します。
> whoami -fqdn CN=Administrator,CN=Users,DC=corp,DC=non-97,DC=net
WorkSpacesの作成に使うユーザーが所属するOUとしてtestOUを作成します。
# 現在のOU一覧を確認
> Get-ADOrganizationalUnit -Filter "*" -SearchBase "DC=corp,DC=non-97,DC=net"
City :
Country :
DistinguishedName : OU=Domain Controllers,DC=corp,DC=non-97,DC=net
LinkedGroupPolicyObjects : {CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=corp,DC=non-97,DC=net}
ManagedBy :
Name : Domain Controllers
ObjectClass : organizationalUnit
ObjectGUID : 81937cb9-16fe-42da-a0d3-7a08362e1212
PostalCode :
State :
StreetAddress :
# testOU を作成
> New-ADOrganizationalUnit -Name testOU -Path "DC=corp,DC=non-97,DC=net" -ProtectedFromAccidentalDeletion $True
# testOU が作成されたことを確認
> Get-ADOrganizationalUnit -Filter "*" -SearchBase "DC=corp,DC=non-97,DC=net"
City :
Country :
DistinguishedName : OU=Domain Controllers,DC=corp,DC=non-97,DC=net
LinkedGroupPolicyObjects : {CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=corp,DC=non-97,DC=net}
ManagedBy :
Name : Domain Controllers
ObjectClass : organizationalUnit
ObjectGUID : 81937cb9-16fe-42da-a0d3-7a08362e1212
PostalCode :
State :
StreetAddress :
City :
Country :
DistinguishedName : OU=testOU,DC=corp,DC=non-97,DC=net
LinkedGroupPolicyObjects : {}
ManagedBy :
Name : testOU
ObjectClass : organizationalUnit
ObjectGUID : 0f79e9a6-e39b-4281-b54e-d9ffa1764970
PostalCode :
State :
StreetAddress :
作成したtestOU配下にtest-1、test-2というユーザーを作成します。
# ユーザー test-1 を作成 > New-ADUser ` -Name "test-1" ` -UserPrincipalName "test-1@corp.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=testOU,DC=corp,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # ユーザー test-2 を作成 > New-ADUser ` -Name "test-2" ` -UserPrincipalName "test-2@corp.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=testOU,DC=corp,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # ユーザーが作成されたことを確認 > Get-ADUser -Filter "*" -SearchBase "OU=testOU,DC=corp,DC=non-97,DC=net" DistinguishedName : CN=test-1,OU=testOU,DC=corp,DC=non-97,DC=net Enabled : True GivenName : Name : test-1 ObjectClass : user ObjectGUID : 21ee0160-c746-4ca4-9775-980e9a80100f SamAccountName : test-1 SID : S-1-5-21-2040492921-3148248736-547483213-1104 Surname : UserPrincipalName : test-1@corp.non-97.net DistinguishedName : CN=test-2,OU=testOU,DC=corp,DC=non-97,DC=net Enabled : True GivenName : Name : test-2 ObjectClass : user ObjectGUID : 7dc30835-9dde-4f16-a16e-7cd360a0d934 SamAccountName : test-2 SID : S-1-5-21-2040492921-3148248736-547483213-1105 Surname : UserPrincipalName : test-2@corp.non-97.net
Managed Microsoft ADの設定
Managed Microsoft ADを管理するEC2インスタンスの設定
続いて、Managed Microsoft ADの設定を行います。
まず、以下記事を参考にManaged Microsoft ADを管理するEC2インスタンスに必要な機能をインストールします。
> $result = Install-WindowsFeature -Name RSAT-ADDS,RSAT-DNS-Server,GPMC > $result.FeatureResult Display Name Name Success # Msg Restart Needed Skip Reason ------------ ---- ------- ----- -------------- ----------- Group Policy Management GPMC True 0 False NotSkipped Remote Server Administration Tools RSAT True 0 False NotSkipped Active Directory Administrative Center RSAT-AD-Adm... True 0 False NotSkipped Active Directory module for Windows... RSAT-AD-Pow... True 0 False NotSkipped AD DS and AD LDS Tools RSAT-AD-Tools True 0 False NotSkipped AD DS Tools RSAT-ADDS True 0 False NotSkipped AD DS Snap-Ins and Command-Line Tools RSAT-ADDS-T... True 0 False NotSkipped DNS Server Tools RSAT-DNS-Se... True 0 False NotSkipped Role Administration Tools RSAT-Role-T... True 0 False NotSkipped
インストール後、Managed Microsoft ADのドメイン(managed-msad.non-97.net)に参加します。
> $password=ConvertTo-SecureString -AsPlainText -Force "<Managed Microsoft ADのAdminのパスワード>"
> $credential=New-Object System.Management.Automation.PSCredential("managed-msad.non-97.net\Admin",$password)
> Add-Computer -DomainName managed-msad.non-97.net -Credential $credential -Restart -Force
OS再起動後、managed-msad.non-97.net\AdminでRDP接続します。接続後、Managed Microsoft ADのAdminでログインしていることを確認します。
PS C:\Users\Admin> whoami -fqdn CN=Admin,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net
比較用としてこちらのドメインにもユーザーを2つほど作成します。
# ユーザー test-A を作成 > New-ADUser ` -Name "test-A" ` -UserPrincipalName "test-A@managed-msad.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # ユーザー test-B を作成 > New-ADUser ` -Name "test-B" ` -UserPrincipalName "test-B@managed-msad.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # ユーザーが作成されたことを確認 > Get-ADUser -Filter "*" -SearchBase "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" DistinguishedName : CN=Admin,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : Admin ObjectClass : user ObjectGUID : 5fd2cca9-8ae5-4426-bee7-6fa6dfcc5b5f SamAccountName : Admin SID : S-1-5-21-3454652377-3764961328-2350928461-1113 Surname : UserPrincipalName : admin@managed-msad.non-97.net DistinguishedName : CN=test-A,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : test-A ObjectClass : user ObjectGUID : bf4ad690-7a2e-4b58-afd3-df26108ed609 SamAccountName : test-A SID : S-1-5-21-3454652377-3764961328-2350928461-1611 Surname : UserPrincipalName : test-A@managed-msad.non-97.net DistinguishedName : CN=test-B,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : test-B ObjectClass : user ObjectGUID : 2e98e506-5d93-49a0-9e71-c8bf2770f770 SamAccountName : test-B SID : S-1-5-21-3454652377-3764961328-2350928461-1612 Surname : UserPrincipalName : test-B@managed-msad.non-97.net
Managed Microsoft ADからセルフマネージドADへの片方向の信頼関係を作成
セルフマネージドADのセキュリティグループのインバウンドルールを編集する
以下記事を参考にManaged Microsoft ADからセルフマネージドADに片方向の信頼関係を作成します。
お互いのADが通信できる必要があるので、セキュリティグループで互いが使用しているセキュリティグループからのトラフィックを許可します。
セルフマネージドADのセキュリティグループのインバウンドルールを確認すると、何もルールがありませんでした。
インバウンドルールを編集して、Managed Microsoft ADが使用しているセキュリティグループからの全てのトラフィックを許可します。
ちなみにアウトバウンドルールは0.0.0.0/0に対して全てのトラフィックを許可しているので、編集する必要はありません。
Managed Microsoft ADのセキュリティグループのアウトバウンドルールを編集する
同様にManaged Microsoft ADのセキュリティグループも確認します。
アウトバウンドルールを確認すると、同じセキュリティグループにしか許可していないです。
アウトバウンドルールを編集して、セルフマネージドADが使用しているセキュリティグループへの全てのトラフィックを許可します。
条件付きフォワーダーの設定
次に条件付きフォワーダーの設定を行います。
セルフマネージドADのEC2インスタンスにcorp.non-97.net\AdministratorでRDP接続します。
Managed Microsoft ADのドメインへの名前解決はManaged Microsoft ADのDNS IPアドレスに転送するように条件付きフォワーダーを作成します。
# 条件付きフォワーダーの作成
> $fqdn = 'managed-msad.non-97.net'
> $dnsServers = @('10.0.1.139','10.0.1.189') # Managed Microsoft ADのDNS IPアドレス
> $params = @{
Name = $fqdn
MasterServers = $dnsServers
ReplicationScope = 'Domain'
}
> Add-DnsServerConditionalForwarderZone @params
# 条件付きフォワーダーが作成されたことを確認
> Get-DnsServerZone
ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigne
d
-------- -------- ------------- -------------- ------------------- -------
_msdcs.corp.non-97.net Primary False True False False
0.in-addr.arpa Primary True False True False
127.in-addr.arpa Primary True False True False
255.in-addr.arpa Primary True False True False
corp.non-97.net Primary False True False False
managed-msad.non-97.net Forwarder False True False
TrustAnchors Primary False True False False
DNS Managerからも条件付きフォワーダーが設定されていることを確認します。
信頼関係の設定 (セルフマネージドAD側)
それでは、信頼関係を作成していきます。
まず、セルフマネージドAD側から設定します。
今回はManaged Microsoft ADからセルフマネージドADへの片方向の信頼関係にしたいので、信頼の方向はInboundにしています。また、信頼は外部の信頼ではなく、フォレストの信頼にします。
> $targetForestName = 'managed-msad.non-97.net' > $trustPassword = '<信頼パスワード (後でManaged Microsoft AD設定時に使う)>' > $trustDirection = 'Inbound' > $forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest() > $forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustDirection, $trustPassword)
設定が完了したらActive Directory Domains and Trusts(Active Directory ドメインと信頼関係)を起動し、Incoming trusts(入力方向の信頼)が作成されていることを確認します。
信頼関係の設定 (Managed Microsoft AD側)
Managed Microsoft AD側でも信頼関係の作成を行います。
AWSのコンソールから対象のManaged Microsoft ADを選択し、信頼関係を追加をクリックします。
フォレストの信頼で、セルフマネージドADのドメインに対して出力方向で信頼するように信頼関係を作成します。
信頼パスワードはセルフマネージドADで信頼関係を設定した時のパスワードを使用します。また、条件付きフォワーダーのIPアドレスはセルフマネージドADのIPアドレスを指定します。
信頼関係を作成して、しばらく待つとステータスが検証済みになります。
WorkSpacesの作成
ディレクトリの登録
それでは、WorkSpacesを作成をしていきます。
まず、下準備としてWorkSpacesがManaged Microsoft ADを参照できるように、ディレクトリの登録を行います。
登録したいディレクトリを選択して、アクション-登録をクリックします。
登録時には異なるAZのサブネットを2つ指定します。しかし、私がWorkSpacesがサポートしているAZにサブネットを作成していなかったので、ディレクトリの登録ができませんでした。
ということで、WorkSpacesがサポートしているAZに新しくサブネットを作成します。
WorkSpacesがインターネットに出れるように、作成したサブネットにNAT Gatewayへのルートがあるルートテーブルを割り当てます。
再度、ディレクトリの登録にチャレンジします。
今回は異なるAZのサブネットを選択できました。登録をクリックします。
ディレクトリの登録済みがTrueになりました。
登録されたディレクトリの詳細を確認すると、以下のようになっていました。
試しにターゲットドメインと組織単位を編集をクリックすると、Managed Microsoft ADのOUの一覧が表示されました。信頼しているドメインのOUはここには表示されないようですね。
WorkSpacesの作成
全ての下準備ができたので、WorkSpacesを作成させます。
WorkSpacesの作成をクリックします。
登録したディレクトリを選択して、次へをクリックします。
信頼されたドメインを選択します。
セルフマネージドADのcorp.non-97.netが選択して、次へをクリックします。
すると、「ディレクトリは使用できません。AD Connector アカウントの場合は、認証情報が正しいことを確認してください。」とエラーが出力されてしまいました。
30分ほど待ったり、ブラウザのリロードをしてみても、こちらのエラーは解消されませんでした。
一方、信頼されたドメインでManaged Microsoft ADのドメインを指定した場合は以下のようにユーザーを選択できました。
そのため、WorkSpacesからManaged Microsoft ADへの連携自体に問題なさそうです。
もしかしたら、信頼関係が双方向でなく、片方向であることが原因かもしれません。
信頼関係の再設定
ということで、信頼関係を試しに双方向にします。
2つのドメイン間に作成できる信頼関係は1つのみです。
AWS Managed Microsoft AD とさまざまな Active Directory ドメイン間で、複数の信頼関係を作成できます。ただし、各ペアが一度に保持できる信頼関係は 1 つのみです。例えば、既に一方向の「受信の信頼」が存在し、その上で「送信方向」で別の信頼関係の設定が必要な場合は、まず既存の信頼関係を削除してから、新たに「双方向」の信頼を作成します。
そのため、同じドメイン間で新しく信頼関係を作成しようとしてもエラーになります。
$targetForestName = 'managed-msad.non-97.net'
$trustPassword = '<信頼パスワード>'
$trustDirection = 'Bidirectional' # 双方向
$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustDirection, $trustPassword)
Exception calling "CreateLocalSideOfTrustRelationship" with "3" argument(s): "The RPC server is unavailable.
Name: "WIN-NL5UH6PN4BF.managed-msad.non-97.net"
"
At line:6 char:1
+ $forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustD ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ActiveDirectoryServerDownException
一度信頼関係を削除してから、双方向の信頼関係を作成を作成します。
まず、セルフマネージドAD側の設定から行います。
# 現在の信頼関係を確認 > $forest.GetAllTrustRelationships() TopLevelNames : ExcludedTopLevelNames : TrustedDomainInformation : SourceName : corp.non-97.net TargetName : managed-msad.non-97.net TrustType : Forest TrustDirection : Inbound # 信頼関係を削除 > $forest.DeleteLocalSideOfTrustRelationship($targetForestName) # 信頼関係が削除されたことを確認 > $forest.GetAllTrustRelationships() # 双方向の信頼関係を作成 > $trustDirection = 'Bidirectional' > $forest.CreateLocalSideOfTrustRelationship($targetForestName, $trustDirection, $trustPassword) # 双方向の信頼関係が作成されたことを確認 > $forest.GetAllTrustRelationships() TopLevelNames : ExcludedTopLevelNames : TrustedDomainInformation : SourceName : corp.non-97.net TargetName : managed-msad.non-97.net TrustType : Forest TrustDirection : Bidirectional
Managed Microsoft AD側も同様に、一度信頼関係を削除してから双方向の信頼関係を作成します。
信頼関係を選択してアクション-信頼関係を削除をクリックします。
削除をクリックします。
削除後、双方向の信頼関係を作成します。
同じように作成しても面白くないので、AWS CLIを使って行います。
# 条件付きフォワーダーは削除されていないことを確認
$ aws ds describe-conditional-forwarders \
--directory-id d-9067b86803
{
"ConditionalForwarders": [
{
"RemoteDomainName": "corp.non-97.net",
"DnsIpAddrs": [
"10.0.1.79"
],
"ReplicationScope": "Domain"
}
]
}
# セルフマネージドADと双方向の信頼関係を作成
$ aws ds create-trust \
--directory-id d-9067b86803 \
--remote-domain-name corp.non-97.net \
--trust-password "F2wNZgCWtJx4DjN3-upiGgL@nTH44yvU" \
--trust-direction "Two-Way" \
--trust-type Forest
{
"TrustId": "t-9067702db2"
}
# 信頼関係が作成中であることを確認
$ aws ds describe-trusts \
--directory-id d-9067b86803
{
"Trusts": [
{
"DirectoryId": "d-9067b86803",
"TrustId": "t-9067702db2",
"RemoteDomainName": "corp.non-97.net",
"TrustType": "Forest",
"TrustDirection": "Two-Way",
"TrustState": "Creating",
"CreatedDateTime": "2022-09-27T11:59:31.563000+00:00",
"LastUpdatedDateTime": "2022-09-27T11:59:31.563000+00:00",
"StateLastUpdatedDateTime": "2022-09-27T11:59:31.563000+00:00",
"SelectiveAuth": "Disabled"
}
]
}
# 信頼関係が検証済みになったことを確認
$ aws ds describe-trusts \
--directory-id d-9067b86803
{
"Trusts": [
{
"DirectoryId": "d-9067b86803",
"TrustId": "t-9067702db2",
"RemoteDomainName": "corp.non-97.net",
"TrustType": "Forest",
"TrustDirection": "Two-Way",
"TrustState": "Verified",
"CreatedDateTime": "2022-09-27T11:59:31.563000+00:00",
"LastUpdatedDateTime": "2022-09-27T12:00:03.848000+00:00",
"StateLastUpdatedDateTime": "2022-09-27T12:00:03.848000+00:00",
"SelectiveAuth": "Disabled"
}
]
}
信頼関係再作成後、再度セルフマネージドADのユーザーでWorkSpacesを作成しようとしましたが、同様に「ディレクトリは使用できません。AD Connector アカウントの場合は、認証情報が正しいことを確認してください。」とエラーが出力されてしまいました。
ドメインユーザーを作り直してみる
WorkSpacesの作成ができるユーザーは姓と名、メールアドレスが設定されている必要があります。
セルフマネージドADに登録したユーザーはいずれも指定していませんでした。
> Get-ADUser -Filter "*" -SearchBase "OU=testOU,DC=corp,DC=non-97,DC=net" DistinguishedName : CN=test-1,OU=testOU,DC=corp,DC=non-97,DC=net Enabled : True GivenName : Name : test-1 ObjectClass : user ObjectGUID : 21ee0160-c746-4ca4-9775-980e9a80100f SamAccountName : test-1 SID : S-1-5-21-2040492921-3148248736-547483213-1104 Surname : UserPrincipalName : test-1@corp.non-97.net DistinguishedName : CN=test-2,OU=testOU,DC=corp,DC=non-97,DC=net Enabled : True GivenName : Name : test-2 ObjectClass : user ObjectGUID : 7dc30835-9dde-4f16-a16e-7cd360a0d934 SamAccountName : test-2 SID : S-1-5-21-2040492921-3148248736-547483213-1105 Surname : UserPrincipalName : test-2@corp.non-97.net
ということで、セルフマネージドADのユーザーに姓と名、メールアドレスを設定します。
PowerShellで新規にドメインユーザーを作成する場合は、以下のようになります。
# ユーザー test-1 を再作成 > New-ADUser ` -Name "test-1" ` -Surname "test" ` -GivenName "1" ` -EmailAddress "<メールアドレス>" ` -UserPrincipalName "test-1@corp.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=testOU,DC=corp,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # ユーザー test-2 を再作成 > New-ADUser ` -Name "test-2" ` -Surname "test" ` -GivenName "2" ` -EmailAddress "<メールアドレス>" ` -UserPrincipalName "test-2@corp.non-97.net" ` -Accountpassword (Read-Host -AsSecureString "AccountPassword") ` -Path "OU=testOU,DC=corp,DC=non-97,DC=net" ` -PasswordNeverExpires $True ` -Enabled $True AccountPassword: ******************************** # ユーザーが作成されたことを確認 > Get-ADUser -Filter "*" -SearchBase "OU=testOU,DC=corp,DC=non-97,DC=net" DistinguishedName : CN=test-1,OU=testOU,DC=corp,DC=non-97,DC=net Enabled : True GivenName : 1 Name : test-1 ObjectClass : user ObjectGUID : 4e76515e-c361-406b-8327-513a9033abdd SamAccountName : test-1 SID : S-1-5-21-2040492921-3148248736-547483213-1108 Surname : test UserPrincipalName : test-1@corp.non-97.net DistinguishedName : CN=test-2,OU=testOU,DC=corp,DC=non-97,DC=net Enabled : True GivenName : 2 Name : test-2 ObjectClass : user ObjectGUID : c311cf36-4b3c-4f9a-ae77-f74f956b9ec1 SamAccountName : test-2 SID : S-1-5-21-2040492921-3148248736-547483213-1109 Surname : test UserPrincipalName : test-2@corp.non-97.net
この状態で、セルフマネージドADのユーザーを使ってWorkSpacesを作成しようとしてみます。
すると、セルフマネージドADのユーザー一覧が表示されることを確認できました。
もしや...と思い、セルフマネージドADのユーザーから姓と名、メールアドレスの情報を削除した状態でも一覧が表示できるか確認してみると、表示できました。
もしかしたら、双方向で信頼関係を再作成してから、リトライまでが短かったためエラーが出たかもしれませんね。
以上のことから「信頼しているドメインのユーザーでWorkSpacesを作成する場合、登録しているディレクトリと双方向の信頼関係である必要がある」と判断できると思います。
WorkSpacesの作成 (2回目)
信頼しているセルフマネージドADのユーザー一覧が表示できたので、WorkSpacesの作成を行なっていきます。
セルフマネージドADのユーザーtest-1を選択して次へをクリックします。
最も安価なバンドルであるValue with Amazon Linux 2を選択して次へをクリックします。
WorkSpaces の料金は以下AWS公式の料金表をご覧ください。
WorkSpacesの設定はデフォルトの1時間のAutoStopのまま、次へをクリックします。
カスタマイズは特に行いません。そのまま次へをクリックします。
最後に確認です。問題なければWorkSpacesの作成をクリックします。
WorkSpacesが作成されていることを確認します。
20分程度待つと、ステータスが使用可能になっていました。
信頼しているドメインのユーザーでWorkSpacesを作成した場合は、招待メールは送られません。
AD Connector または信頼されたドメインを使用している場合、招待メールはユーザーに自動的には送信されないため、手動で送信する必要があります。また、ユーザーが既に Active Directory に存在する場合も、招待メールは自動的に送信されません。
コンソールに表示されている登録コードを確認しておきます。確認したコードをWorkSpacesのクライアントに入力し、Registerをクリックします。
ドメインユーザーの認証情報を入力して、Sign Inをクリックします。
すると、「Unknown Error Occurred」 と怒られてしまいました。
こちらのエラーを調べてみると、ネットワークの前提条件を満たせていない可能性があると情報がありました。
このエラーは通常、WorkSpaces クライアントがポート 443 で認証できても、TCP ポート 4172 で接続を確立できないことを示します。ネットワークの前提条件を満たしていない場合に、発生する可能性があります。クライアント側の問題により、クライアントのネットワークチェックが失敗する可能性があります。右上隅のアイコンを選択して、どのヘルスチェックが失敗しているかを確認します。
WorkSpacesを作成したリージョンはus-east-1です。もしかしたら日本とは距離がありすぎてRTTの制限が引っかかっているかもしれません。
PCoIP のパフォーマンスを最大限に高めるには、クライアントネットワークから WorkSpaces があるリージョンまでのラウンドトリップ時間 (RTT) が 100ms 未満でなければなりません。RTT が 100 ミリ秒から 200 ミリ秒の間にある場合、ユーザーは WorkSpace にアクセスできますが、パフォーマンスに影響します。RTT が 200 ミリ秒～375 ミリ秒の間にある場合、パフォーマンスは低下します。RTT が 375 ミリ秒を超えると、WorkSpaces クライアント接続は終了します。
WorkSpacesのログも確認してみます。
~/Library/Application\ Support/Amazon\ Web\ Services/Amazon\ WorkSpaces/logs/配下に出力されたログを見ると、WorkspaceStateChange: Authenticatedとあることから認証まではできていそうですが、証明書のエラーで弾かれていそうです。
2022-09-28T02:44:04.841Z { Version: "5.3.0.2446" }: [DBG] Username/password are used for authentication
2022-09-28T02:44:04.851Z { Version: "5.3.0.2446" }: [DBG] Authenticate Request Session-Id: cd256da0-a1ae-4bc6-a2e0-f18ff3c198fb Amzn-id: 84a316c7-aea6-4269-a10c-e18aebd4c940
2022-09-28T02:44:06.027Z { Version: "5.3.0.2446" }: [DBG] Received Http AuthenticateResponse(Url: https://ws-broker-service.us-east-1.amazonaws.com/)
2022-09-28T02:44:06.060Z { Version: "5.3.0.2446" }: [DBG] WorkspaceStateChange: Authenticated
2022-09-28T02:44:06.062Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> Authenticate::Error=0
2022-09-28T02:44:06.063Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> Authenticate::Fault=0
2022-09-28T02:44:06.063Z { Version: "5.3.0.2446" }: [INF] setting failure action in no op heart beat task
2022-09-28T02:44:06.063Z { Version: "5.3.0.2446" }: [INF] Starting no op heart beat task
2022-09-28T02:44:06.064Z { Version: "5.3.0.2446" }: [INF] Navigating to Use Case WorkSpacesClient.Common.UseCases.PrepareWorkspaceUseCase.PrepareWorkspacePresenter
2022-09-28T02:44:06.073Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> WdUserAuth::Error=0
2022-09-28T02:44:06.074Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> WdUserAuth::Fault=0
2022-09-28T02:44:06.088Z { Version: "5.3.0.2446" }: [DBG] WorkspaceStateChange: Processing
2022-09-28T02:44:06.088Z { Version: "5.3.0.2446" }: [DBG] GetResources Request Session-Id: cd256da0-a1ae-4bc6-a2e0-f18ff3c198fb Amzn-id: bc3191f2-9f3f-464e-90fe-f0de6fce9b9b
2022-09-28T02:44:06.449Z { Version: "5.3.0.2446" }: [DBG] Received Http GetResourcesResponse(Url: https://ws-broker-service.us-east-1.amazonaws.com/) with [(ResourceId: ws-b7dpfngf0, ResourceType: WORKSPACE)]
2022-09-28T02:44:06.453Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> GetResources::Error=0
2022-09-28T02:44:06.455Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> GetResources::Fault=0
2022-09-28T02:44:06.460Z { Version: "5.3.0.2446" }: [DBG] Received resource, Protocol: Pcoip
2022-09-28T02:44:06.460Z { Version: "5.3.0.2446" }: [WRN] Using Default Enum value for type: WorkSpacesClient.Common.Constants.WSPendingAction and Value
2022-09-28T02:44:06.460Z { Version: "5.3.0.2446" }: [WRN] Using Default Enum value for type: WorkSpacesClient.Common.Constants.WSPendingAction and Value
2022-09-28T02:44:06.461Z { Version: "5.3.0.2446" }: [INF] Allocating resource with resourceId/workspaceId: ws-b7dpfngf0.
2022-09-28T02:44:06.461Z { Version: "5.3.0.2446" }: [INF] Detected time zone in macOS: Asia/Tokyo
2022-09-28T02:44:06.461Z { Version: "5.3.0.2446" }: [INF] Determined Equivalent Windows TimeZone: Tokyo Standard Time
2022-09-28T02:44:06.461Z { Version: "5.3.0.2446" }: [INF] Detected time zone in macOS: Asia/Tokyo
2022-09-28T02:44:06.461Z { Version: "5.3.0.2446" }: [INF] Determined Equivalent Windows TimeZone: Tokyo Standard Time
2022-09-28T02:44:06.461Z { Version: "5.3.0.2446" }: [DBG] PerformResourceActionRequest Type: CONNECT, Protocol: PCOIP, Session-Id: cd256da0-a1ae-4bc6-a2e0-f18ff3c198fb, Amzn-id: 2c46d869-de42-4e45-913c-250bfe5151af
2022-09-28T02:44:06.837Z { Version: "5.3.0.2446" }: [DBG] Received Http AllocateResourceResponse(Url: $https://ws-broker-service.us-east-1.amazonaws.com/) with (ResultType: SUCCESS_REDIRECT, ResultValues.SessionId: 53e6b892ebdeb304de6898f4c535d0e7)
2022-09-28T02:44:06.838Z { Version: "5.3.0.2446" }: [INF] AllocateResource Action successfully performed
2022-09-28T02:44:06.838Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> Connect::Cancel=0
2022-09-28T02:44:06.843Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> Connect::Error=0
2022-09-28T02:44:06.847Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> Connect::Fault=0
2022-09-28T02:44:06.870Z { Version: "5.3.0.2446" }: [DBG] WorkspaceStateChange: Processing
2022-09-28T02:44:06.871Z { Version: "5.3.0.2446" }: [INF] Navigating to Use Case WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionPresenter
2022-09-28T02:44:06.889Z { Version: "5.3.0.2446" }: [DBG] WorkspaceStateChange: Processing
2022-09-28T02:44:06.889Z { Version: "5.3.0.2446" }: [INF] Detected time zone in macOS: Asia/Tokyo
2022-09-28T02:44:06.889Z { Version: "5.3.0.2446" }: [INF] Determined Equivalent Windows TimeZone: Tokyo Standard Time
2022-09-28T02:44:06.889Z { Version: "5.3.0.2446" }: [DBG] Provision Session Request: gw:dcd9b7256f16f10a91d3c104ef5d50d3 | 3.235.115.131 | 4172
2022-09-28T02:44:07.469Z { Version: "5.3.0.2446" }: [DBG] StreamProtocol: Tls12
2022-09-28T02:44:13.275Z { Version: "5.3.0.2446" }: [DBG] Sent Metrics Request to https://skylight-client-ds.us-east-1.amazonaws.com/put-metrics:
2022-09-28T02:44:24.461Z { Version: "5.3.0.2446" }: [DBG] Provision Session Response Received
2022-09-28T02:44:24.464Z { Version: "5.3.0.2446" }: [ERR] SessionProvision: Connection to target failed. SNI: -----BEGIN CERTIFICATE----- MIICtTCCAh4CCQDOm+yJwEETiTANBgkqhkiG9w0BAQwFADCBnjELMAkGA1UEBhMC VVMxEzARBgNVBAgMCldhc2hpbmd0b24xEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNV BAoME0FtYXpvbiBXZWIgU2VydmljZXMxEjAQBgNVBAsMCVNvZnRQQ29JUDEeMBwG CSqGSIb3DQEJAwwPU2VjdXJpdHlHYXRld2F5MRYwFAYDVQQDDA0zLjIzNS4xMTUu MTMxMB4XDTIyMDkyMzIyNDYzNloXDTI3MDkyMjIyNDYzNlowgZ4xCzAJBgNVBAYT AlVTMRMwEQYDVQQIDApXYXNoaW5ndG9uMRAwDgYDVQQHDAdTZWF0dGxlMRwwGgYD VQQKDBNBbWF6b24gV2ViIFNlcnZpY2VzMRIwEAYDVQQLDAlTb2Z0UENvSVAxHjAc BgkqhkiG9w0BCQMMD1NlY3VyaXR5R2F0ZXdheTEWMBQGA1UEAwwNMy4yMzUuMTE1 LjEzMTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs82Jt5PM3VlVxZNWJVLz +zyo46vyLrJQtee7FxbqEIbRxApx0gZLlmutNhn886AIvixIjZoC7rfmgSrm4V/z dhx17+0ygmwGPIZGMjC/IJcZdzrDFSIiStfBX26M7lritwPO3DM5pRj8FqD+zCMt VBHfxlJTHbJegLeVEvznoAkCAwEAATANBgkqhkiG9w0BAQwFAAOBgQCYVw/mS0hE PUyj4krU6tcCZwYIHf87DoBeRtUOV1RrmOy5SRVKAcCbC5To/mSJVXLAB/30jPMo 0UIlJFVLHW9fXRE0rJSUmwigPoF68ImLO5hLw1yy541J4mTI5itIQlm0B1PiW4Al ihS2GkGSCnmW0nqYqAUYn6pwoN/F2oGphQ== -----END CERTIFICATE----- | IP: 3.235.115.131
2022-09-28T02:44:24.468Z { Version: "5.3.0.2446" }: [ERR] Unknown error while SessionProvision: WorkSpacesClient.Common.Infrastructure.ExceptionHandler.WorkspacesClientException: PcoipSessionProvisionUnknownError
at WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionInteractor.CheckAndThrowOnError (WorkSpacesClient.Common.Entity.BrokerProvisionSessionResponse response) [0x0008a] in <0c028c211f0d487b83399e37eded1118>:0
at WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionInteractor.ProvisionSession (WorkSpacesClient.Common.Entity.Session session, System.Collections.Generic.IEnumerable`1[T] targets, System.Threading.CancellationToken cancellationToken) [0x0015b] in <0c028c211f0d487b83399e37eded1118>:0
2022-09-28T02:44:24.468Z { Version: "5.3.0.2446" }: [DBG] Provision Session Request: gw:dcd9b7256f16f10a91d3c104ef5d50d3 | 3.217.228.179 | 4172
2022-09-28T02:44:25.118Z { Version: "5.3.0.2446" }: [DBG] StreamProtocol: Tls12
2022-09-28T02:44:25.372Z { Version: "5.3.0.2446" }: [DBG] Provision Session Response Received
2022-09-28T02:44:25.372Z { Version: "5.3.0.2446" }: [ERR] SessionProvision: Connection to target failed. SNI: -----BEGIN CERTIFICATE----- MIICtTCCAh4CCQC1wVEhRzJdYDANBgkqhkiG9w0BAQwFADCBnjELMAkGA1UEBhMC VVMxEzARBgNVBAgMCldhc2hpbmd0b24xEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNV BAoME0FtYXpvbiBXZWIgU2VydmljZXMxEjAQBgNVBAsMCVNvZnRQQ29JUDEeMBwG CSqGSIb3DQEJAwwPU2VjdXJpdHlHYXRld2F5MRYwFAYDVQQDDA0zLjIxNy4yMjgu MTc5MB4XDTIyMDkyMzA1MjcyNloXDTI3MDkyMjA1MjcyNlowgZ4xCzAJBgNVBAYT AlVTMRMwEQYDVQQIDApXYXNoaW5ndG9uMRAwDgYDVQQHDAdTZWF0dGxlMRwwGgYD VQQKDBNBbWF6b24gV2ViIFNlcnZpY2VzMRIwEAYDVQQLDAlTb2Z0UENvSVAxHjAc BgkqhkiG9w0BCQMMD1NlY3VyaXR5R2F0ZXdheTEWMBQGA1UEAwwNMy4yMTcuMjI4 LjE3OTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsXDHhpQUT0r0vPj+KRRj nD6LdQAHeWyhx0/WlfjaH9Fv920qRNElwu9U6mF+sfiDzusd5V6SbnVOoOIGdhCT Ba9KWmrg1GEw04ayZ7Ejd1Yz0S1FLsGVkMDCGpkx8q329G3mayhrkhh2KQlwDV6R 5MjQZo3MVMY2mVI2K+5RvB0CAwEAATANBgkqhkiG9w0BAQwFAAOBgQCRQ4ziDPtz oZkSGNsroslBOWbteaKWiXFB7H5zt361vsF9Qcsdn2ULtb7dVRcrjXplTHTAsjSl t7sxO03pg5otDpoLNKgZ4VZ271OQC6XyG4WzDvK4AHsQs1REJbssQ5mQeLdS0Z54 OPdX2HOuxEFkOt5CA2O5V/Vw6mY0+W7/gA== -----END CERTIFICATE----- | IP: 3.217.228.179
2022-09-28T02:44:25.373Z { Version: "5.3.0.2446" }: [ERR] Unknown error while SessionProvision: WorkSpacesClient.Common.Infrastructure.ExceptionHandler.WorkspacesClientException: PcoipSessionProvisionUnknownError
at WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionInteractor.CheckAndThrowOnError (WorkSpacesClient.Common.Entity.BrokerProvisionSessionResponse response) [0x0008a] in <0c028c211f0d487b83399e37eded1118>:0
at WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionInteractor.ProvisionSession (WorkSpacesClient.Common.Entity.Session session, System.Collections.Generic.IEnumerable`1[T] targets, System.Threading.CancellationToken cancellationToken) [0x0015b] in <0c028c211f0d487b83399e37eded1118>:0
2022-09-28T02:44:25.373Z { Version: "5.3.0.2446" }: [DBG] Provision Session Request: gw:dcd9b7256f16f10a91d3c104ef5d50d3 | 3.235.112.156 | 4172
2022-09-28T02:44:25.949Z { Version: "5.3.0.2446" }: [DBG] StreamProtocol: Tls12
2022-09-28T02:44:26.221Z { Version: "5.3.0.2446" }: [DBG] Provision Session Response Received
2022-09-28T02:44:26.221Z { Version: "5.3.0.2446" }: [ERR] SessionProvision: Connection to target failed. SNI: -----BEGIN CERTIFICATE----- MIICtTCCAh4CCQCCVEfleU/6qDANBgkqhkiG9w0BAQwFADCBnjELMAkGA1UEBhMC VVMxEzARBgNVBAgMCldhc2hpbmd0b24xEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNV BAoME0FtYXpvbiBXZWIgU2VydmljZXMxEjAQBgNVBAsMCVNvZnRQQ29JUDEeMBwG CSqGSIb3DQEJAwwPU2VjdXJpdHlHYXRld2F5MRYwFAYDVQQDDA0zLjIzNS4xMTIu MTU2MB4XDTIyMDkyMzIyNDczNloXDTI3MDkyMjIyNDczNlowgZ4xCzAJBgNVBAYT AlVTMRMwEQYDVQQIDApXYXNoaW5ndG9uMRAwDgYDVQQHDAdTZWF0dGxlMRwwGgYD VQQKDBNBbWF6b24gV2ViIFNlcnZpY2VzMRIwEAYDVQQLDAlTb2Z0UENvSVAxHjAc BgkqhkiG9w0BCQMMD1NlY3VyaXR5R2F0ZXdheTEWMBQGA1UEAwwNMy4yMzUuMTEy LjE1NjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAszNbkYidFNfPhi+lVnY1 Pw54dzLtNWWc2/Riz3XsuUEfDUDDkUoD6C9IzJ7eIpdS9/dBEODXBMaarPB2jT1m ZRe+bC50aqwdVXImmFPGXQ/+TY9NhW/QdsiOfrNPif5hnN2LYfzjh5RN4QHEZwdm QR4nKbuLvUHQGkQH36qxT+sCAwEAATANBgkqhkiG9w0BAQwFAAOBgQAkVskLrhbx MVVekF4RfTHU4DdnJigAZDPF8OplrQVaYXlKB2YDL9QKHrZc90sQzdUplGQ4w+rM FcAbG/fGo/4Hzy1SzJDD33h/O4BV+1iMQoB31diQAqf5qY6iYNIeqhTqJ/MDt4+H HclqTU1LzeaCuMPdeWuJ3dF08IquwiDzNw== -----END CERTIFICATE----- | IP: 3.235.112.156
2022-09-28T02:44:26.222Z { Version: "5.3.0.2446" }: [ERR] Unknown error while SessionProvision: WorkSpacesClient.Common.Infrastructure.ExceptionHandler.WorkspacesClientException: PcoipSessionProvisionUnknownError
at WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionInteractor.CheckAndThrowOnError (WorkSpacesClient.Common.Entity.BrokerProvisionSessionResponse response) [0x0008a] in <0c028c211f0d487b83399e37eded1118>:0
at WorkSpacesClient.Common.UseCases.SessionProvisionUseCase.SessionProvisionInteractor.ProvisionSession (WorkSpacesClient.Common.Entity.Session session, System.Collections.Generic.IEnumerable`1[T] targets, System.Threading.CancellationToken cancellationToken) [0x0015b] in <0c028c211f0d487b83399e37eded1118>:0
2022-09-28T02:44:26.222Z { Version: "5.3.0.2446" }: [ERR] SessionProvision tried all targets, but failed to establish connections to any.
2022-09-28T02:44:26.222Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> SessionProvision::Error=0
2022-09-28T02:44:26.225Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> SessionProvision::Fault=1
2022-09-28T02:44:26.252Z { Version: "5.3.0.2446" }: [DBG] WorkspaceStateChange: Processing
2022-09-28T02:44:26.253Z { Version: "5.3.0.2446" }: [INF] Navigating to Use Case WorkSpacesClient.Common.UseCases.ErrorUseCase.ErrorPresenter
2022-09-28T02:44:26.258Z { Version: "5.3.0.2446" }: [DBG] GetResources Request Session-Id: cd256da0-a1ae-4bc6-a2e0-f18ff3c198fb Amzn-id: 688467c0-121a-4d80-ab0f-45bc24eedae6
2022-09-28T02:44:26.259Z { Version: "5.3.0.2446" }: [INF] Remote login setting: True. Current Local admin setting: True
2022-09-28T02:44:26.259Z { Version: "5.3.0.2446" }: [INF] shouldShowReconnectButton resolved to 'False'
2022-09-28T02:44:26.259Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> ConnectAttempt::Fault=1
2022-09-28T02:44:26.260Z { Version: "5.3.0.2446" }: [ERR] Showing error page with code: PcoipSessionProvisionWorkspaceTargetsExhausted
2022-09-28T02:44:26.260Z { Version: "5.3.0.2446" }: [WRN] Stopping heartbeat task as we're entering error view
2022-09-28T02:44:26.260Z { Version: "5.3.0.2446" }: [INF] stopping no op heart beat task
2022-09-28T02:44:27.392Z { Version: "5.3.0.2446" }: [DBG] Received Http GetResourcesResponse(Url: https://ws-broker-service.us-east-1.amazonaws.com/) with [(ResourceId: ws-b7dpfngf0, ResourceType: WORKSPACE)]
2022-09-28T02:44:27.395Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> GetResources::Error=0
2022-09-28T02:44:27.397Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> GetResources::Fault=0
2022-09-28T02:44:27.400Z { Version: "5.3.0.2446" }: [DBG] Recording Metric-> WorkSpacesStatus::WorkSpacesStatusError=0
2022-09-28T02:44:33.273Z { Version: "5.3.0.2446" }: [DBG] Sent Metrics Request to https://skylight-client-ds.us-east-1.amazonaws.com/put-metrics:
問題切り分けのために、Managed Microsoft AD上のユーザー(managd-msad.non-97.net\test-A)でもWorkSpacesを作成させてみます。
バンドルなどの設定は同じにしましたが、こちらのWorkSpacesには接続できました。
Developers IOのURLにcurlでアクセスしましたが、HTTPステータスコードが200であることから、インターネットにもアクセスできていそうですね。
また、IPアドレスは以下のようになっていました。
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0e:90:1b:7d:24:cd brd ff:ff:ff:ff:ff:ff
inet 198.19.184.143/18 brd 198.19.191.255 scope global dynamic eth0
valid_lft 2962sec preferred_lft 2962sec
inet6 fe80::c90:1bff:fe7d:24cd/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0e:cf:26:91:14:a7 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.87/27 brd 10.0.1.95 scope global dynamic eth1
valid_lft 3056sec preferred_lft 3056sec
inet6 fe80::ccf:26ff:fe91:14a7/64 scope link
valid_lft forever preferred_lft forever
WorkSpacesの作成 (3回目)
Managed Microsoft AD上のユーザーだとWorkSpacesに接続できるとなると、ネットワーク要件は満たしていそうです。そのため、信頼しているドメインの問題になりそうです。
もしかしたら、ログに出力されていた証明書のエラーメッセージは、接続しようとしているWorkSpacesでは信頼しているドメインの証明書を検証できなかったことを表しているのかもしれません。そして証明書を検証できない原因はLinuxのイメージを使っているからかもしれません。
試しにWindowsでWorkSpacesを作り直してみます。
まず、Linuxのイメージで作成したWorkSpacesを削除します。
削除をクリックします。
WorkSpacesが削除されたことを確認します。WorkSpacesの作成をクリックします。
ユーザーは先ほどと同じ信頼しているドメインのユーザー(test-1)です。
ちなみにManaged Microsoft ADのドメインを選択すると、信頼しているドメインのユーザーが表示されました。
Managed Microsoft ADのユーザー一覧を確認すると、Enabled : falseのドメインユーザーが作成されていました。謎ですね。
> Get-ADUser -Filter "*" -SearchBase "OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net" DistinguishedName : CN=Admin,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : Admin ObjectClass : user ObjectGUID : 5fd2cca9-8ae5-4426-bee7-6fa6dfcc5b5f SamAccountName : Admin SID : S-1-5-21-3454652377-3764961328-2350928461-1113 Surname : UserPrincipalName : admin@managed-msad.non-97.net DistinguishedName : CN=test-A,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : A Name : test-A ObjectClass : user ObjectGUID : bf4ad690-7a2e-4b58-afd3-df26108ed609 SamAccountName : test-A SID : S-1-5-21-3454652377-3764961328-2350928461-1611 Surname : test UserPrincipalName : test-A@managed-msad.non-97.net DistinguishedName : CN=test-B,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : test-B ObjectClass : user ObjectGUID : 2e98e506-5d93-49a0-9e71-c8bf2770f770 SamAccountName : test-B SID : S-1-5-21-3454652377-3764961328-2350928461-1612 Surname : UserPrincipalName : test-B@managed-msad.non-97.net DistinguishedName : CN=CORP$,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : True GivenName : Name : CORP$ ObjectClass : user ObjectGUID : a8e38035-67db-48b6-beef-efb661297a8a SamAccountName : CORP$ SID : S-1-5-21-3454652377-3764961328-2350928461-1147 Surname : UserPrincipalName : DistinguishedName : CN=test-1,OU=Users,OU=managed-msad,DC=managed-msad,DC=non-97,DC=net Enabled : False GivenName : 1 Name : test-1 ObjectClass : user ObjectGUID : 07a2a2af-e368-44ef-8a06-a24825006c9e SamAccountName : test-1 SID : S-1-5-21-3454652377-3764961328-2350928461-1148 Surname : test UserPrincipalName : test-1@MANAGED-MSAD.NON-97.NET
WorkSpacesの作成に話を戻します。
バンドルはWindowsのものを選択します。それ以外の設定は先ほどと全て同じです。
設定内容を確認して、WorkSpacesの作成をクリックします。
20分ほど待つとステータスが使用可能になったので、接続してみます。
接続できましたね。信頼されているドメインのユーザーでWorkSpacesを使う場合は、Linuxのバンドルではできず、Windowsのバンドルを使う必要があるようです。
ユーザーのパスワードを入力して、ログインします。
WorkSpacesの壁紙が表示されました。嬉しいです。
whoamiでログインしているユーザーのドメインを確認します。corp\test-1なので、確かに信頼しているドメインのユーザーのようです。セキュリティグループは特に割り当てられていないようですね。
なお、WorkSpacesのマシン自体はManaged Microsoft ADのドメインに参加していました。
参考までにIPアドレスの情報は以下の通りです。
先ほどとは別のIPアドレスが割り当てられていますね。
AWS CLIでWorkSpacesが使っているENIを確認すると、各WorkSpacesのENIが作成されていました。
aws ec2 describe-network-interfaces \
--filters \
Name=vpc-id,Values=vpc-031941bfabc38456d \
Name=group-name,Values=d-9067b86803_workspacesMembers
{
"NetworkInterfaces": [
{
"Attachment": {
"AttachTime": "2022-09-28T03:58:56+00:00",
"AttachmentId": "eni-attach-0a827a8fdbbb3e864",
"DeleteOnTermination": false,
"DeviceIndex": 1,
"NetworkCardIndex": 0,
"InstanceOwnerId": "697148468905",
"Status": "attached"
},
"AvailabilityZone": "us-east-1a",
"Description": "Created By Amazon Workspaces for AWS Account ID <AWSアカウントID>",
"Groups": [
{
"GroupName": "d-9067b86803_workspacesMembers",
"GroupId": "sg-0077854c3ae0ce770"
}
],
"InterfaceType": "interface",
"Ipv6Addresses": [],
"MacAddress": "0e:cf:26:91:14:a7",
"NetworkInterfaceId": "eni-0e47bb8dbceba68a2",
"OwnerId": "<AWSアカウントID>",
"PrivateDnsName": "ip-10-0-1-87.ec2.internal",
"PrivateIpAddress": "10.0.1.87",
"PrivateIpAddresses": [
{
"Primary": true,
"PrivateDnsName": "ip-10-0-1-87.ec2.internal",
"PrivateIpAddress": "10.0.1.87"
}
],
"RequesterId": "AROA6KUFAVPUXLTQYJFIO:WorkSpace-Creation",
"RequesterManaged": false,
"SourceDestCheck": true,
"Status": "in-use",
"SubnetId": "subnet-01105c76744a2fc83",
"TagSet": [],
"VpcId": "vpc-031941bfabc38456d"
},
{
"Attachment": {
"AttachTime": "2022-09-28T08:43:52+00:00",
"AttachmentId": "eni-attach-0cf3c99d7dd2e58e4",
"DeleteOnTermination": false,
"DeviceIndex": 1,
"NetworkCardIndex": 0,
"InstanceOwnerId": "697148468905",
"Status": "attached"
},
"AvailabilityZone": "us-east-1a",
"Description": "Created By Amazon Workspaces for AWS Account ID <AWSアカウントID>",
"Groups": [
{
"GroupName": "d-9067b86803_workspacesMembers",
"GroupId": "sg-0077854c3ae0ce770"
}
],
"InterfaceType": "interface",
"Ipv6Addresses": [],
"MacAddress": "0e:9a:1b:7b:a1:03",
"NetworkInterfaceId": "eni-09e8e4856f45cf760",
"OwnerId": "<AWSアカウントID>",
"PrivateDnsName": "ip-10-0-1-86.ec2.internal",
"PrivateIpAddress": "10.0.1.86",
"PrivateIpAddresses": [
{
"Primary": true,
"PrivateDnsName": "ip-10-0-1-86.ec2.internal",
"PrivateIpAddress": "10.0.1.86"
}
],
"RequesterId": "AROA6KUFAVPUXLTQYJFIO:WorkSpace-Creation",
"RequesterManaged": false,
"SourceDestCheck": true,
"Status": "in-use",
"SubnetId": "subnet-01105c76744a2fc83",
"TagSet": [],
"VpcId": "vpc-031941bfabc38456d"
}
]
}
WorkSpacesを大量に作る場合は、サブネットに空きIPアドレスがあるか常にチェックしておきたいですね。
信頼されたドメインのユーザーをWorkSpacesで使う場合は気をつけよう
Managed Microsoft ADと信頼関係にあるセルフマネージドADのユーザーを使ってAmazon WorkSpacesを作成してみました。
信頼しているドメインユーザーでWorkSpacesを使用する場合は、信頼関係は双方向で作成し、Windowsバンドルを利用することが分かりました。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Workshop] Hands-on: How software vendors can use the Amazon Q Business index に参加しました #AIM333 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[アップデート]Amazon Connectがフロー内での録音に対応しました！留守番電話を簡単に設定できるようになりました #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3nibOl2sZ0LKJueI0FHFi5/14de7bd294f7916a28b789105c60d450/reinvent-2024-newservice-jp.jpg)
